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ABSTRACT 


The integrated mobile alert system (IMAS) is a mobile device messaging 
system that provides a means for people to stay connected and receive 
information in a modality that is constantly available to them. It was developed 
and built into a proof-of-concept (PoC) system at the Naval Postgraduate School 
(NPS) from commercial off the shelf (COTS) products. Like other systems, this 
system suffers from vulnerabilities because of bugs. These bugs come from (1) 
COTS products, (2) design of the system and (3) developed 
processes/applications. The study will review the design of IMAS, its processes 
and the COTS products. The focus of the study is to review these components 
and identify potential vulnerabilities. Furthermore, it will explain how these 
vulnerabilities may be exploited by probable threats. It will recommend solutions 
that can correct or prevent vulnerabilities. Lastly, the thesis will propose other 
measures that would make the system more secure. 
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I. INTRODUCTION 


A. BACKGROUND 

In today’s modern society, mobile devices are getting smaller, more 
powerful and packed with many functionalities that people use to surf the web, 
listen to their favorite songs or even watch a movie. It is no wonder that they 
have become an ubiquitous facet of our daily lives. Carrying a mobile device 
allows individuals to stay connected with their family, friends or business 
associates. People today carry more than one mobile device with them, e.g., 
cellular phones, smart-phones, BlackBerry, Portable Digital Assistant (PDA), 
pagers and laptops 

A mobile alert is a mode of push communication whereby users are 
notified or informed of a piece of information/event by their mobile devices. This 
could be in the form of a page by a pager, simple text message (SMS), 
multimedia message (MMS), e-mail, voice-mail or instant message (IM) that is 
readily available to the mobile devices. Hence, with mobile alerts, people are 
able to stay connected to the world they live in. They may receive the latest stock 
price information from the stock market, a reminder of an appointment, a 
situational awareness report of the battleground by troops, an emergency alert 
from authorities and many others. 

However, there are times when the mode of reaching a person is 
inappropriate, i.e., it is context-insensitive to the environment in which the person 
is located. A person in a meeting, watching a movie, or attending a concert, 
would prohibit the ring of a call. Therefore, it would be nice if an integrated 
mobile alert system (IMAS) was available - a system that could transform the 
mobile alerts into a mode that is appropriate and non-interruptive to the 
environment that person is in. The person may specify the environment and the 
mode of alerts they prefer to receive. That way, an alert could always reach the 
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person regardless of the environment they are in. Two students, Hsu and Le [1], 
took this idea and built a proof-of-concept (PoC) system using commercial-off- 
the-shelf (COTS) products to illustrate the advantages of this system. 

B. PURPOSE 

The purpose of this thesis is to study and evaluate IMAS and identify 
vulnerabilities in the system so that solutions or mitigation methods can be 
proposed to secure the system. The vulnerabilities come from all components of 
IMAS. These components include: 

• COTS products 

• Design and implementation of IMAS 

• Applications/functions 

Figure 1 shows the software components that compose IMAS. It consists 
of in-house developed web applications and COTS products. The COTS 

products used in IMAS include (1) the operating system (Windows 2003 Server 
Standard Edition), (2) the web server (IIS6.0), (3) the scripting language (PHP) 
and (4) the database server (MySOL 5.0.18).The focus of this thesis is to review 
these components and identify potential vulnerabilities. Furthermore, it will 
explain how these vulnerabilities may be exploited by probable threats. It will 
recommend solutions that can correct or prevent vulnerabilities. Lastly, the thesis 
will propose other measures that would make the system more secure. 


Web Applications 


IIS6.0 

PHP 

MySQL 

Operating System 
(Windows 2003 Server) 


Figure 1. IMAS supporting components 
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C. ASSUMPTIONS 

In this thesis, certain assumptions are being made so that the evaluation, 
solutions and mitigation methods proposed are valid in the assumed context and 
environment. 

1. Personnel 

It is assumed that all personnel accessing the system are trustworthy, i.e., 
their security clearances have been verified and they have received appropriate 
security training. This will prevent them from jeopardizing the system and putting 
the security of the system at risk. It will also be assumed that all personnel will 
follow all requisite procedures for system access. 

2. Deployment of System 

It is assumed that the system is deployed in a secure room where physical 
access to the room is controlled either by a personal identification number (PIN)- 
based entry system or a smart-card/magnetic-striped entry system. This allows 
only authorized personnel to access the room after they have cleared the 
identification and authentication process. In addition, this type of entry system 
provides an entry record for audit to be conducted and reviewed. The walls and 
ceiling of the room are assumed to be hardened to prevent easy penetration. 

3. Physical Computer Security 

The system is assumed to be protected by a common access card (CAC) 
system to prevent un-authorized personnel from accessing the system physically. 
Only authorized personnel with a valid CAC card authenticated by the system 
can access the applications. Procedures will be in-place requiring a person to 
either log off or lock their computers via “screen lock” when leaving the system 
unattended for a pre-determined period of time. 

4. Limitations 

Due to limited time available, the software codes of in-house developed 
processes/applications and the database design will not be analyzed in this 
thesis. 
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II. COTS PRODUCTS AND THEIR VULNERABILITIES 


A. INTRODUCTION TO IMAS 

IMAS is created to provide a common medium for people to stay 
connected by receiving alerts across a wide variety of platforms. It allows users 
to configure their daily schedules and mode of alerts they wish to receive. The 
system can then coordinate the sources of alerts and reconstruct them to reach 
the users in the most appropriate and non-interruptive way. 

Unfortunately, like many systems, IMAS suffers from security 
vulnerabilities that make it an easy target for attacks. The sources of these 
vulnerabilities include components that are used to develop the system and 
system design and implementation bugs. The components include COTS 
products like the hardware, operating systems, commercial applications and in- 
house developed applications. The attacks often lead to (1) system crashes, (2) 
corruption of data, (3) theft of information, or (4) sending of alerts to a wrong 
party. These attacks are disastrous and undesirable to both the system and the 
people involved. Hence, to ensure that IMAS is not subjected to subversion and 
exploitation, these vulnerabilities must be removed or prevented. 

IMAS is composed of COTS products and in-house developed 
applications. The former provides the infrastructure and general services while 
the latter provides specific services pertaining to IMAS. COTS products are often 
vulnerable because of bugs in (1) software codes, (2) design errors in the 
applications and (3) mis-configurations in the installations. This chapter will 
review the COTS products used in IMAS and highlight common vulnerabilities 
reported in each component. Furthermore, it will recommend best-practiced 
methods to reduce and mitigate vulnerabilities. It will cover: (1) the operating 
system (Windows 2003 server standard edition) that manages the system, (2) 
the web server (IIS6.0) that hosts the web pages, (3) the scripting language 
(PHP) that is used to create the applications and (4) the database (MySOL) that 
stores and retrieves data. 
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B. WINDOWS 2003 SERVER 

The operating system, Windows 2003 server standard edition in the case 
of IMAS, is the core of any system. It manages the resources of the system and 
ensures that all requests, locally or remotely, from the applications run timely and 
successfully. Windows 2003 server is considered the most secure and reliable 
operating system to date. It is built by Microsoft under the Trustworthy Computing 
initiative. Under this initiative, the programmers were trained to write secure 
codes. These codes are inspected and scrutinized for vulnerabilities. In addition, 
Windows 2003 server simplifies the usage and management of its suite of 
security functionalities, e.g., public key infrastructure (PKI) authentication 
services, single-sign-on (SSO) session and identity management control. The 
security functions prevent or minimize users from making mistakes that might 
violate the security of the system. A special tool, security configuration wizard 
(SCW), is also incorporated into the operating system to help users configure the 
system in the most secure mode. In this mode, all unused services are turned off 
by the operating system by default and no administrator is allowed to logon 
remotely using a null password. [2] 

Despite this, Windows 2003 server still suffers from vulnerability attacks. 
Figure 2 shows a vulnerability report on Windows 2003 server standard edition 
published by Secunia [3], from January to November 2006. There were 
vulnerabilities reported every month except for March. 
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Microsoft Windows Server 2003 Standard Edition 
Advisories (Based on 30 advisories from 2006) 
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This graph ns generated by secunia. 

Based on vulnerability information available at http: secunia.com, 


Figure 2. Number of vulnerabilities reported 


Figure 3 shows that among the vulnerabilities reported, only 93% of them 
could be fixed with patches and no patches were available for the remaining 7%. 


Microsoft Windows Server 2003 Standard Edition 
Soiution Status (Based on 30 advisories from 2006) 

■ Unpatched (7%) 

□ Vendor Patch (93%) 

□ Vendor Workaround (0%) 

□ Partial fix (0%) 


This graph .-.’as generated by becunia. 

Based on vulnerability information available at http://secunia.com/ 

Figure 3. Solution Status 

Figure 4 shows that among the vulnerabilities found, 10% were extremely 
critical and 30% were rated highly critical. This 40% requires immediate remedy 
actions to be taken. 
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Microsoft Windows Server 2003 Standard Edition 
Criticaiity (Based on 30 advisories from 2006) 



■ Extremely (10%) 

□ Highly (30%) 

□ Moderately (27%) 

□ Less (30%) 

□ Not (3%) 


This graph •vas generated by Secunia. 

Based on vulnerability information available at http://secunia.com/ 


Figure 4. Criticality report of the vulnerability 


Figure 5 shows that on vulnerability-based attacks, 90% were launched 
from network-based systems. Of these attacks, 63% were from remote systems 
and 27% from local network systems. The remaining 10% came from local 
systems. 


Microsoft Windows Server 2003 Standard Edition 
Where (Based on 30 advisories from 2006) 

El From remote (63%) 

■ From local netiwork (27%) 
□ Local system (10%) 


This graph .■.■^s generated by Secunia. 

Based on vulnerability information available at http:/.’5ecunia.com/ 



Figure 5. Location of attack 


Figure 6 shows that among the vulnerability-based attacks, 58% were 
system-accessed in nature while the other attacks such as denial-of-service 
(DoS) and privilege-escalation took up 18% and 13%, respectively. 
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Microsoft Windows Server 2003 Standard Edition 
Impact (Based on 30 advisories from 2006) 

■ System access (S8%) 

□ DoS (18%) 

□ Privilege escalation (13%) 

□ Exposure sensitive info (3%) 

■ Exposure system info (3%) 

■ Brute Force (0%) 

■ Manipulation of data (0%) 

□ Spoofing (3%) 

□ Cross Site Scripting (2%) 

□ Security bypass (0%) 

■ Hijacking (0%) 

□ Unknown (0%) 

This graph was generated by Secunia 

B^sed on vulnerability information available at http://-iecunia.com/ 

Figure 6. Types of attacks 

1. Common Vulnerabilities 

Among the vulnerabilities reported on Windows 2003 server standard 
edition that surfaced from 2005 to 2006 by SecurityFocus [4], it was discovered 
that most of the reported vulnerabilities come from bugs or design errors in the 
software code. A majority of the vulnerabilities reported fell into three primary 
areas: (1) boundary condition error, (2) failure to handle exceptional conditions 
and (3) input validation error. These vulnerabilities were found in (1) Internet 
Explorer (IE) 6 (the web browser that comes bundled with Windows 2003 server), 
(2) window libraries in the likes of “.dll” files and (3) windows explorer. These 
vulnerabilities could lead to many potential remote attacks. For instance, 
malicious media files, web pages, or images could be used to crash the system 
and prevent it from delivering service. Flence, to prevent the system from 
succumbing to these types of vulnerability exploits, it is necessary to determine 
the presence of these vulnerabilities and fix them. 

2. How to Determine if the System Is at Risk 

The common practice to determine if the system is at risk is to use a 

vulnerability scanner such as Nessus or Microsoft Baseline Security Analyzer 

(MBSA) .These tools allow the users to determine the system vulnerabilities’ 

presence so that actions can be taken to resolve or mitigate them. Nessus is a 

security tool that scans all the ports used by the services running on the system(s) 
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and also tries to exploit these ports. MBSA is a vulnerability tool offered by 
Microsoft that checks the configuration of the operating system for missing 
patches, user accounts without passwords and available updates. It will highlight 
any vulnerabilities that do not conform to its security checklist. Both scanner 
programs provide users with a report that highlights vulnerabilities detected. 

3. How to Protect against Vulnerabilities 

Once the vulnerabilities have been determined, necessary steps must be 
taken to reduce them and protect the system. Some of the best practices 
adopted are as follows. 

a. Windows Updates and Patches 

Ensure that patches and service packs (hot-fixes) are always up-to- 
date to prevent any exploitation of vulnerabilities. Windows 2003 server provides 
the user with options to update the patches and service packs automatically. 
However, as the patches might introduce additional bugs and vulnerabilities, it is 
advisable to update patches only when a common consensus is reached among 
all security advisories. 

b. Disable/Rename Default Accounts 

As part of the process of securing the server, all un-used default 
accounts must be disabled or renamed. In Windows 2003 server, there are 
numerous built-in accounts that can be used by default as shown in Figure 7. 
This is a common thread for attack. 
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Figure 7. Default accounts 


To prevent this type of attack, it is mandatory to always change the 
name or disable default accounts. Accounts in Windows 2003 server that are 
highly common (and built-in) are the Guest and Administrator accounts. It is 
recommended to rename the default Administrator account to enhance system 
security. It is also advisable to create a backup Administrator account to protect 
primary Administrator account log-out. [5] 

c. Install Anti-Virus Software 

Currently, most viruses are created to attack Windows systems. To 
prevent such attacks, anti-virus software must be installed and signatures must 
be updated regularly. In addition, the system must be scanned regularly to 
ensure that it is free of viruses. Norton and MacAfee are two popular choices for 
anti-virus software. 
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d. Other Protection Measures 

Other security measures recommended to protect the system 
include the following: 

• Implement NTFS (New Technology File System) - NTFS is a 
windows file system developed for Windows NT that provides a 
good method to implement security on the file system. It provides 
the capability to impose an access-control list (ACL) to files and 
folders, thereby permitting or disallowing peoples’ access. In the 
newest NTFS, i.e., NTFS5, it provides additional capability to 
encrypt files and folders. This will keep files safe from intruders who 
might try to gain unauthorized physical access to sensitive and 
stored data. 

• Disk Segmentation - it is always advisable to separate specific 
data, e.g., sensitive and non-sensitive data, on separate physical 
disks. This prevents attackers from traversing the web site directory 
trees inside the web server. This in turn provides another security 
layer to deter attackers from gaining access to the cmd.exe utility 
remotely. 

• Install Host-based Intrusion protection System (HIPS) /Host- 
based Intrusion detection system (HIDS) - this agent, which is 
installed on the system, monitors activities in the system against a 
set of specific patterns or signatures. If an anomaly activity is 
detected, it will either block the activity by the HIPS or inform the 
user through HIDS. 

C. IIS6.0 

IIS6.0, which comes bundled with Windows 2003 server, was designed to 
be a secure product. It was re-architected and built on a Windows Server 2003 
platform exclusively. Most of the services and features were turned off by default 
to prevent any possible attacks. In the new architecture, all web applications are 
serviced individually by a dedicated worker process in an application pool. 
Therefore, if one process fails, it will not affect other processes. In addition, the 
anonymous account, which comes with IIS6.0 by default no longer, has write 
permissions on the default web root folder. This prevents any attacker from 
taking advantage of this vulnerability. [6] However, like Windows 2003 server, it 
lends itself to vulnerabilities because of bugs and design errors in the software 
code. 
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1. Reported Vulnerabilities 

Among the vulnerabilities reported by SecurityFocus [7], the most noted 
vulnerabilities are those pertaining to (1) remote buffer overflow, (2) web admin 
console, (2) disclosure of IP and (4) internal address. All of these vulnerabilities 
stem from the application’s inability to validate input or design errors in the 
software code. 

2. How to Determine the Vulnerabilities 

The vulnerabilities of IIS6.0 can be determined by the use of a 
vulnerability scanner such as Nessus or MBSA. All services and ports identified 
by Nessus can be checked against IIS6.0 to determine if they are needed. Any 
un-used ports and services should be turned off. MBSA would determine the 
latest patches and fixes that should be patched to prevent IIS6.0 from possible 
vulnerabilities. 

3. How to Protect against Vulnerabilities 

a. Windows Updates and Patches 

Ensure patches and service packs (hot-fixes) are always up to date 
to prevent any exploitation of vulnerabilities. However, as patches might 
introduce bugs, it is advisable to update patches only when a common 
consensus is reached among all the security advisories. 

b. Auditing and Logging 

Logging must always be enabled to keep track of all accesses and 
requests made at the web server. The auditing provides valuable information 
about possible attacks on the web server, which is useful during incident 
handling. To prevent log files from being accessed by un-authorized personnel, it 
should be secured with NTFS permissions. Log files should also be audited on a 
routine basis to detect any anomaly activity. 

c. Access-Controi 

Access-control should always be in place to deter or defend against 
attackers. It can be applied to (1) control applications running on the server, (2) 
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restrict files served by the server and (3) limit access to the web site hosted by 
the server. To ensure access-control security, the following recommendations 
are made [8]: 

• Applications - only enable those web service extensions that have a 
corresponding application or web service hosted on the web server. 
By default, IIS6.0 enables ASP, ASP.NET, Front Page Server 
extensions, Internet Data Connector (IDC), Server Side Include 
(SSI). It is recommended to disable all unknown ISAPI extensions 
or all unknown CGI extensions. This will reduce the probability of 
vulnerability attacks associated with these applications. 

• Files - only enable those files that are served by the server. It is 
recommended never to enable wildcard as this will permit IIS6.0 
to serve any file type (including .ini, .bat) to the client. This will 
increase the probability of handling any malicious files. 

• Website permissions - website permissions should always be 
exercised with caution and be granted on an as-needed basis. By 
default, all users from the Internet are granted read permission that 
allows them to view the contents hosted by the server. Write and 
executable permissions are disabled by default. This prevents any 
un-authorized person from the Internet to upload malicious files to 
the server or execute malicious scripts on the server. Flence, it is 
recommended to grant write and executable permissions on an as- 
needed basis. It is also recommended to put all executable and 
script files in one directory so that it is easy to configure access 
permissions and audit special access permissions. 

• User accounts - IIS6.0 provides four built-in accounts: (1) 
LocalSystem account that is part of the administrators group which 
has administrator rights, (2) Network Service account that has 
fewer permissions on the system, (3) Local Service account that 
has the same privileges as the Network Service account on the 
local machine but cannot access resources across the network and 
(4) IIS_WPG group account that is assigned minimum permissions. 
This account is also used to start any worker process. It is 
recommended to assign users to either the Network Service 
account or the Local Service account depending on the services 
and resources they required. No users should be assigned to 
LocalSystem account because this account has a high level of 
access rights and has been a target for many exploits. 

D. PHP SCRIPTING LANGUAGE 

PFIP is the most widely used scripting language for the web. Based on 

some reports, 50% of the Apache servers world-wide have PFIP installed. A large 

number of Content Management Systems (CMS), portals and bulletin boards (BB) 
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are written in PHP. Despite its popularity and widespread-usage, PHP is plagued 
with vulnerabilities. It was reported by SANS that in 2005, a problem was 
reported at least every single week in some software using PHP. [9] 

1. Common Vulnerabilities 

Some of the common vulnerabilities reported include the following. 

a. PHP Package Vulnerability 

This vulnerability is found in the PHP package itself and is caused 
by flaws in the way the PHP package software handles POST requests. It was 
reported that each of these flaws could allow an attacker to execute arbitrary 
code on the remote system. 

b. Remote File Vulnerability 

This vulnerability is found inside the application using PHP and is 
due to the application’s failure to handle maliciously crafted file properly. This 
allows an attacker to run malicious code on the vulnerable web server. 

c. Remote Command Execution Vulnerability 

This vulnerability is found in applications using PHP and is due to 
the application’s failure to process data that contains commands properly. This 
allows attackers to execute commands remotely that may compromise the 
application and underlying system. 

d. SQL Injection Vulnerability 

This vulnerability is found in applications using PHP and is due to 
the application’s failure to sanitize variables used to construct SQL queries. This 
permits attackers to inject SQL code into the variables. This attack is commonly 
used to recover password hashes for administrators of the PHP applications. 

e. Remote Code Execution in Library Vulnerability 

This vulnerability is found in libraries using PHP and is due to a 
failure in the library to properly conduct a sanity check on the input. This permits 
attackers to execute code remotely in libraries. The “Lupper worm” is a worm that 
was created to exploit remote execution vulnerabilities in these libraries. 
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2. How to Determine the Vulnerabilities 

The vulnerabilities of PHP can be determined by scanning the web 
servers periodically with a vulnerability scanner. Common PHP vulnerability 
scanners are (1) Acunetix web vulnerability scanner [10], (2) remote PHP 
vulnerability scanner [11] and (3) File inclusion scanner [12]. 

3. How to Protect against Vulnerabilities 

The best practices to protect against PHP vulnerabilities are listed as 
follows. 

a. Update Patches 

Always apply all vendor patches for PHP and PHP-based 

applications. 

b. Web Scanning 

Always run a vulnerability scanner on the web site frequently or 

periodically. 

c. Secure PHP Configuration 

Always secure PHP configuration by disabling the parameters 
“register_globals”, “allow_url_fopen” and “magic_gpc_quotes” and enabling the 
parameters “safe_mode” and “open_basedir”. 

d. Run SQL injection Test 

Always conduct automated SQL injection tests against PHP 
applications hosted by the web server using web application security assessment 
tools like Paros Proxy. 

e. Adopt PoLP (Principie of Least Priviiege) 

Always adopt POLP for running PHP using tools such as 
PHPsuExec, and php_suexec. These are modules/software that allow users to 
impose ACL on the PHP files. This allows only limited/authorized persons to 
access and operate PHP files. 

f. Upgrade 

Always upgrade to the latest version of PHP as it will eliminate 
many existing PHP security issues. At the time of this writing, the latest version is 
PHP 5. 
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g. External Protection Mechanisms 

Always use an intrusion prevention/detection system that will 
block/alert any malicious HTTP request(s). 

E. SQL 

Databases are a key element for data storage, searching or manipulation 
in many systems. They can be found virtually everywhere, from businesses, 
financial and banking institutions, to schools and anywhere that requires 
manipulation of large data. Due to the valuable information they store such as 
passwords and financial details, they are often a target of attacks. [13] To make 
matters worse, these attacks could be easily conducted by anybody who has a 
query tool because most modern relational databases are port addressable. The 
attackers could connect directly to the database using the query tool and bypass 
security mechanisms used by the operating system. 

1. Common Vulnerabilities 

Among vulnerabilities reported in databases, the most common 
vulnerabilities can be classified into the following categories: 

• Buffer overflows in processes that listen to well-known TCP/UDP 
ports 

• SQL injection via web entry 

• Databases running in default configuration with default usernames 
and passwords 

• Databases running with weak passwords for privileged accounts 

2. How to Determine Vulnerabilities 

The vulnerabilities of the database could be determined by using a 
vulnerability scanner or tools offered from database vendors such as MySQL 
network scanner and Microsoft SQL server tool. 

3. How to Protect against Vulnerabilities 

Some of the recommended practices to protect against database 
vulnerabilities are listed as follows. 

a. Update Patches 

Always ensure all DBMS have up-to-date patches because any un¬ 
patched or outdated versions are likely to contain vulnerabilities. 
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Always check vendor sites for patch information and subscribe to 
vulnerabilities alerts offered by the vendor. For MySQL, the web site is: 
http://lists.mvsql.com/ . 

b. Secure DBMS and Applications 

Always secure DBMS and its applications. This includes: 

• Adopt least privilege principle for DBMS access 

• Remove/change default passwords on the database’s privilege and 

systems accounts 

• Use store procedures where possible 

• Remove/disable unnecessary procedures 

• Set length limits on form fields 

c. Other Security Mechanisms 

Always use firewalls or other security devices to control network 
access to ports associated with database services. 

d. Data Validation 

Always ensure that the application performs data validation and 
sanitation at the server end to prevent attacks such as SQL injection or buffer 
overflow. 

F. CHAPTER SUMMARY 

This chapter observed that CQTS products, typically software components, 
are plagued with vulnerabilities that stem from bugs or design errors in the 
software code. These vulnerabilities are exploited by attackers that often lead to 
(1) system crashes, (2) theft of information or (3) corruption of data. These 
attacks are disastrous to both the system and the people involved, including 
IMAS. Although patches and mitigation methods are always available to reduce 
and prevent against such vulnerabilities, they are reactive in nature. They are 
always available after the vulnerability has been reported. This opens up a 
vulnerability window where systems are susceptible to attacks. In addition, since 
most, if not all software codes contain bugs, users are expected to patch or apply 
mitigation methods whenever a vulnerability is reported. 
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The next chapter reviews the framework of IMAS. It will analyze its design 
and processes to uncover and identify possible vulnerabilities. Furthermore, it will 
discuss how these vulnerabilities are exploited by well-known attacks. It will also 
provide solutions or mitigation techniques to help reduce and prevent these 
vulnerabilities. 
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III. IMAS SECURITY ANALYSIS AND RECOMMENDATIONS 


A. INTRODUCTION 

This chapter studies the framework of IMAS and reviews two areas: (1) its 
design architecture and (2) how in-house developed applications handle input, to 
determine probable vulnerabilities. It will step through the flow of IMAS processes 
to determine probable vulnerabilities in each of them. The study will focus 
specifically on identifying vulnerabilities of in-house developed applications that 
are frequently exploited by common attacks and understand why they succeed. 
Furthermore, it will cover wrong-input-entry vulnerabilities. It will then propose 
various countermeasures to show how these vulnerabilities can be mitigated. In 
addition, the study will suggest security methods to protect the data from 
unauthorized access and modification. Other security measures are 
recommended to make IMAS more secure. 

B. IMAS FRAMEWORK OVERVIEW 

The IMAS system was constructed based on a framework shown in Figure 
8. In this figure, an IMAS user enters the web portal system through a profile 
interface. Flowever, before the user is able to use the system, he/she must create 
an account in the system. Here, the user enters the following information: 

• first name 

• last name 

• desired user name 

• password 

• e-mail address 

• e-mail password 

• IM screen-name 

• IM provider 

• cell-phone number 

• cell-phone provider 

• cell-phone model 


21 




This information, less the cell phone model, is stored in the user profile. 
The cell phone model is stored in the device profile. After registering, the user 
logs into IMAS to enter his/her schedule. Here, they will be presented with a 
calendar menu from which they will select the date of the event. They will then 
enter the (1) description, (2) time, and duration, (3) context and (4) types of alert 
they want to receive. This information is stored in the user profile. IMAS currently 
offers three context types: (1) general, (2) meeting and (3) do not disturb. In the 
general context, the user will receive one of the following: (1) SMS message, (2) 
IM, (3) e-mail, or (4) cell-phone call. In the meeting context, a SMS message, IM, 
or e-mail will be sent. In the do not disturb context, an e-mail is the only alert 
disseminated. According to the user-set parameters in the user profile, when an 
alert comes in through the media storage, IMAS will perform an alert- 
transformation in the alert construction. Here, it transforms the incoming alert to 
an alert specified by the user. After the alert is made, the system sends it to the 
user thorough the alert retrieval and dissemination stage. [14] 


^Oser Profile^ 

(user defined) 
-Location-based 
(user defined) 
•Alert Policy 
(user defined rules) 
-Scheduled Alert 
•Immediate Alert 
Err>ergency Alert 
^.Subscription Algtt-^ 



-IM 
-email 
2. MMS 
-MMS text 
•Video 
•Audio 
-Image 
3 Voioe 
-Telephone 
•Voice mail 
-VOIP 



Profile Interface 
-imported schedule calender 
-(user manual input) 


_Device Profile^ 

- Device Moaei (usenr^ut) 
-Device specs (admin input) 


ALERT CONSTRUCTION 


ALERT RETRIEVAL AND DISSEMINATION 


Figure 8. IMAS Framework 
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C. DESIGN AND IMPLEMENTATION 

The IMAS was built on a single computer (a Dell Optiplex GX270 3.2GHz, 
1GB RAM and 30GB HDD) running all its services/applications and data. 
Although this design and implementation is a cheap and a quick means to build a 
system, it is considered a bad implementation because it is a single point of 
failure. If the box is taken down, all the services will be lost, i.e., loss of 
availability. 

1. Vulnerabilities 

The single-box design implementation suffers vulnerabilities in the 
following areas. 

a. Security 

Since the data is housed in a single box with the 
services/applications, all the data could be compromised if the web server is 
exploited. An attacker could gain access to all the data, even though they are 
housed in different directories. This is known as the directory traversal attack. 
This box could also be used as a launching pad against other corporate 
computer systems if the computer is on a corporate local area network. In 
addition, the attackers could use services not required by IMAS for an exploit. 
This implementation denies the flexibility of deploying other security options. It 
weakens the security of IMAS due to the difficulty of applying appropriate security 
options on different applications and data residing inside the same box. 

b. Management Control 

By incorporating all the services and applications within a single 
box, the management control of people’s access will be complicated. People 
from various departments managing different services or applications are 
required to access the system to maintain and support numerous operations. If 
the management control of personnel access is not handled properly, system 
degradation increases. 
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c. Scalability 

A single-box implementation does not scale well because upgrades 
to applications or the physical box will bring the system down. In addition, it will 
be taxing on computing resources if traffic is heavy. This would lead to a potential 
loss of service when traffic is beyond the threshold of the system. 

2. Tier-Architecture 

The common practice to overcome issues discussed previously is to 
separate applications into tiers and implement them into a 3-tier architecture. [15, 
16] Figure 9 shows an overview of the 3-tier architecture. This architectural tier 
consists of the: (1) web, (2) application and (3) database. 



Figure 9. 3-tier architecture 


The web tier provides static content, e.g., simple FITML pages to users 
with web applications. The application tier provides dynamic content, e.g., 
applications and processing logic, while the database tier provides access to the 
database for data storage and retrieval. 

a. Physical Implementation 

The 3-tier architecture should be implemented using either a 2-box 
or 3-box approach. In the 2-box implementation, the web and application tier are 
co-located and run within a single box while the database tier is in a separate box. 
In the 3-box implementation, each tier is run on a single box. Figure 10 and 
Figure 11 show the 2-box and 3-box physical implementation, respectively. 
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b. Benefits of 3-Tier Architecture 

The 3-tier architecture is recommended over the single-box 
architecture due to numerous benefits it provides. The benefits are discussed as 
follows. 

• Security - The 3-tier architecture offers several security benefits. 
They are listed as follows. 

• Data is better protected - With the separation of applications 
and data into tiers, logically and physically, data does not 
reside in the same box as applications. This provides 
another layer of defense against data access. Hence, if the 
web server is compromised, attackers will not be able to 
access data directly. This prevents information leakage. 

• Impact is minimized - With separation, only the box that is 
compromised is affected. It will not affect other systems on 
the network, i.e., impact is contained within a single box. 
Hence, the impact is minimized. 

• Deployment of appropriate security options - With 
separation, it allows the deployment of appropriate security 
options on different boxes and applications. For example, 
ACL could be applied to the database to control the access. 
The application proxy/FW or host based IPS/IDS/FW could 
also be installed on each box to filter out any 
unwanted/suspicious traffic. 

• Control of unwanted services - With separation, 
services/applications running on each box are better 
controlled. Unwanted services are turned off to prevent 
attackers from exploiting them. 

• Higher Availability - The 3-tier architecture offers a higher 
availability. Each tier can deploy multiple boxes offering the same 
service simultaneously. Therefore, if a single box goes down, 
service will not be disrupted. Instead, the service can be provided 
by the other boxes in the same tier. 

• Stronger Management Control - The 3-tier architecture provides 
stronger management control in two aspects: (1) applications 
running in the system and (2) personnel access. With applications 
de-lineated and separated into tiers, the system can control the 
types of applications running in each box. Applications not 
belonging to the tier will not be allowed to run in the box. This in 
turn, limits the access of personnel supporting the applications. 
Personnel supporting one tier will not be allowed to access the box 
belonging to the other two tiers. 
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• Better Scalability - The 3-tier architecture offers better scalability 
because it allows upgrades (hardware and software) without loss of 
service. Since this architecture offers HA, hardware and software 
upgrades could be implemented incrementally i.e., one box at a 
time without disrupting the service. 

3. Recommended Design and Implementation 

The 2-box approach is recommended for IMAS. This approach is cheaper 
and consumes less bandwidth (as there are fewer tiers). Figure 12 shows the 
proposed 3-tier architecture based on a 2-box approach. 


DMZ 



The servers are deployed inside a demilitarized zone (DMZ) for enhanced 
security. DMZ is an isolated network that sits between the Internet and the 
Intranet. It is protected by two firewalls. The firewall facing the Internet controls 
access between the Internet and DMZ. The firewall facing the Intranet limits 
access from the Intranet to DMZ. It does not allow hosts from DMZ to access the 
Intranet. This prevents attackers from using IMAS as a launching pad to attack 
the Intranet if it is compromised. The database server is placed in a different 
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segment in the DMZ, separated from the web and application server. This 
provides an additional layer of defense, which deters attackers from accessing 
data easily. 

D. PROCESSES 

This section will step through the IMAS processes and identify probable 
vulnerabilities. 

1. Registration 

Registration is the first process a user interacts with IMAS before he/she 
can use the system. In this process, the user registers an account and inputs 
his/her personal and device profile information. However, prior to registration, the 
user must verify that they are gaining access to IMAS and not a bogus server 
hosted by fraudsters. 

a. Vulnerability - Phishing 

“Phishing is a criminal activity using social engineering techniques. 
In this act, phishers attempt to fraudulently acquire sensitive information, such as 
passwords and credit card details, by masquerading as a trustworthy person or 
business in an electronic communication.” [17] In the context of this thesis, 
phishing refers to users being led or directed to a masqueraded web site that 
looks identical to the IMAS. However, it is hosted by attackers without the 
knowledge of end users or IMAS’s owner. When users are on this masqueraded 
web site, they log in and unknowingly release their personal information. 

b. How to Detect Phishing 

There are various ways to determine phishing. The most common 
and effective way is to use anti-phishing software. This software validates if the 
website is a phishing website by checking against a list of reported or blacklisted 
phishing websites. The following is a list of anti-phishing software recommended: 
[18] 

• Earthlink Tool Scamblocker - This software offers a check against 
a list of blacklisted phishing website. It checks the owner and 
location of the web site. In addition, it prevents against phishing and 
pop-ups. 
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• Corestreet’s SpoofStick - This software validates the web site by 
using the browser's internal read-only variables to display the top 
and second level domain name that the user is browsing. 

• TrustWatch Toolbar - This software checks in real-time if the web 
site has been verified by a trusted third party. 

c. How to Prevent Phishing 

Based on studies conducted on anti-phishing [19, 20], it is 
recommended that IMAS implement the following measures: 

• Distinguish the IMAS site from the malicious site - Always use a 
single domain name that matches the system, e.g., www.imas.com 
rather than using an IP address or multiple domain names for the 
server. This enables users to better distinguish the web site from 
malicious web sites. IMAS should not be sharing the web server 
with other web applications to prevent confusion. 

• Public Certificate - IMAS should implement public key 
infrastructure (PKI) technology. PKI is an arrangement that 
provides a trusted third party who completes a validation check and 
vouches for user identities. IMAS should generate a public/private 
key pair and register it with a trusted certificate authority (CA), e.g., 
Verizon, RSA Security Inc., to obtain its digital certificate. CA is a 
trusted third party entity that vets and certifies the identities of the 
users or systems. After certifying, it binds their public keys and their 
identities into a digital certificate signed by the CA. Users may then 
verify the web server using their own web browser. If the server 
uses a certificate that is not signed by a trusted CA, the browser will 
issue a warning alerting the user. 

• Encrypt every page - All the pages in IMAS should be encrypted 
using secure socket layer (SSL) /transport layer security (TLS). 
This will allow the web browser used by the user to authenticate 
that the page comes from IMAS. SSL/TLS are cryptographic 
protocols which provide secure communications on the Internet for 
things such as web browsing, e-mail, Internet faxing, and other data 
transfers. 

2. Establish Secure Communication Channel 

All registrations should be conducted in a secure mode, i.e., all data input 
by users should be encrypted. This is because data submitted by users is 
confidential and sensitive. 

a. Vuinerabiiity - internet Snooping 

By default, communications over the web are conducted in clear 

text using http protocol. If an attacker is eavesdropping or snooping on the 
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Internet, the attacker will know what is being communicated. The attacker may 
then use this information to impersonate the user and gain access to the user’s 
bank account or credit card information. This is disastrous and undesirable. 


Likewise, if the registration for IMAS is conducted in clear text using 
http protocol, it is likely that data will be eavesdropped or intercepted by attackers 
snooping on the Internet. This results in a loss of confidentiality. Thus, to prevent 
this form of vulnerability, it is necessary to establish a secure communication 
channel/session between users and IMAS before and during the registration 
process. This ensures that all data transmitted are secure. This secure 
communication channel must always be established whenever any confidential 
information needs to be communicated between users and IMAS. 

b. How to Establish Secure Communication 
Channel/Session 

IMAS should use SSL/TLS to establish a secure session between 
the web server and the user. SSL/TLS supports two modes of authentication to 
establish a secure communication session: (1) server and (2) server and client. 
In the server-authentication mode, only the server is authenticated by the client. 
Here, the web browser will check the certificate used by the web server. If it is 
not signed by a trusted CA, the web browser will give a warning informing the 
user. In the second mode, the server and client are mutually authenticated. Once 
the authentication is completed, a session key will be generated to encrypt the 
session between the server and the user. This session key is only valid during 
this session. If a new session is established, a new session key is used. 

c. Deployment in Secure Environment 

If IMAS is used in a corporate or secure environment, it is 
recommended to include SSL/TLS server-client authentication together with the 
standard username and password authentication implemented by the system. 
This provides a more restricted access. If the user does not have their CAC that 
stores the private key, then the system will deny the user from establishing a 
session to IMAS. 
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3. Data Process 

In the registration process, an IMAS user will enter the following: (1) e-mail 
address, (2) e-mail password, (3) IM username, (4) IM provider, (5) cell phone 
number, (6) cellular provider and (7) cell phone model. Figure 13 shows the 
registration menu of IMAS. Once the user has input the data and clicked on the 
submit button, the data will then be sent to IMAS for processing. However, 
before data can be processed by any application(s), it must be validated at the 
server-end for correct and non-malicious entry. 
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Figure 13. IMAS registration menu 


a. Vulnerabilities 

The input submitted by users is likely to contain errors due to typing 
errors or “fat finger” mistakes. This leads to incorrect information being captured 
by IMAS. As a result, the system is unable to deliver alerts to the user (causing a 
loss of service) which is detrimental to IMAS effectiveness. Hence, it is vital to 
ensure that data is submitted correctly. 

In addition, data type validation is imperative. Based on a report by 

Gartner, most web application attacks in 2004 [21] were a result of web 

applications’ failure to check and validate input entry before any application 

execution. This creates an opportunity for the attacker to sneak in malicious 

characters or scripts that exploit the vulnerability of the underlying protocols 
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supporting applications such as PHP, MySQL and the operating system. Hence, 
it is also necessary to perform data validation at the trusted server-end, before it 
is being used by the application. 

b. How to Correct Input Entry Errors 
The way to ensure data is free of input entry errors is to perform 
data-correction checks. This section proposes several data-correction check 
methods for each field in the registration menu. These methods leverage 
existing services/programs/scripts available to perform the check to minimize the 
programmer’s effort. The programmer just needs to write a script to use these 
services. However, it should be noted that these services are written by un¬ 
trusted parties. Therefore, it is necessary that these programs be reviewed by a 
group of security programmers to ensure they do not contain malicious code. In 
addition, these programs must be tested rigorously to ensure they do not contain 
malicious codes. The validation check for each field is listed as follows. 

(1) E-mail Address and Password Validation Check. 
There are two ways to validate an e-mail address and password: (1) script or (2) 
external web mail retrieval service. I MAS could leverage these two methods as 
follows: 

• Script - The script polls the mail server with an e-mail address and 
password entry provided by the user. If the e-mail address and 
password entry are valid entries, the mail server will return a 
successful reply. If an unsuccessful reply is received, IMAS can 
provide feedback to the user that the entries submitted are invalid 
and ask him/her to verify the entries. “Pop3 account polling”, is a 
software written in perl script that works on this principle. [22] It 
polls an external POP3 account on a regular basis and retrieves 
any e-mail messages. It then executes an e-mail processing 
program, e.g.. Outlook, and feeds the message text to the 
program's standard input. 

• External web-mail retrieval service - This type of service is available 
free on the Internet [23]. It allows users to retrieve e-mail from any 
POP3 accounts from the web using the user’s e-mail address and 
password entries. If the e-mail and/or password is incorrect, it will 
generate an error message. IMAS would then provide feedback to 
the user. “Mail2web,” [24] is a free service available on the Internet 
that verifies the e-mail address and password. Furthermore, it 
allows for both secure and non-secure log-in. 
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(2) IM Name and IM Provider Validation Check. This 
check leverages the search feature offered by IM client software. This feature 
provides direct access to the provider’s database. Before I MAS can use this 
feature, it must download the IM client software from IM providers e.g., MSN, 
ICQ, Yahoo Messenger, Skype or Jabber into IMAS. IMAS will have a registered 
account for each IM provider utilized by the various users. IMAS can then use the 
search engine of the IM-client software to verify the user’s username. If the 
username is valid, IMAS will add this username to the contact list of the IM client 
software in IMAS. If the user’s entry is invalid, the search will return a null result. 
IMAS can then provide feedback to the user and request a re-verification. 

However, a drawback is that the search might also return a 
list of other users sharing the same username. To refine the search, additional 
fields such as country and e-mail address are required. In the current IMAS 
implementation, the menu only allows the user to input the IM screen-name and 
the IM provider. This limitation prevents the system from verifying the entry 
effectively. In addition, IMAS is inflexible as it only allows the user to input one IM 
account. Nowadays, users typically have more than one IM account. Users may 
need various IM accounts in order to communicate with different groups of 
people, e.g., business associates, friends and family; or for different 
environments. Some IM services are blocked in certain environments. 

Hence, to resolve these issues, the registration menu needs 
to be flexible. It must allow users to add/select more than one IM account. Each 
account should have additional fields to provide a better granularity search. 
Although IM service provides a convenient and almost real-time alert notification 
to reach the user, it should be noted that some IM software is insecure. 
Messages are transmitted in clear text and can be read by anyone with the 
sniffing tools and network access. In addition, messages are vulnerable during 
processing on the server. Messages can also be intercepted, altered and re¬ 
transmitted. Therefore, it is advisable not to send any confidential message or 
alerts via this mode. 
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Fortunately, many popular IM providers (AOL, ICQ, MSN 
messenger and Yahoo messenger), recognize this drawback and have since 
launched a secure-version client software. This software encrypts the message 
between the users to promote a more secure session. For better management of 
different IM-client-software installed on the system, it is recommended that IMAS 
uses unified IM software. This software collates all users’ contacts from the 
various IM providers and presents it as a single IM view. Miranda, is an IM 
software that offers both secure and normal messaging services. [25, 26] 

(3) Cell Phone Number and Service Provider Check. 
There are multiple web sites that provide free services that allow individuals to 
verify the service provider for a given cell phone number. One such service is the 
phone number analysis service provided by International Number Plans [27]. It 
accepts a cell phone number and then returns a service provider. If the service 
provider returned does not match the entry provided, IMAS will provide feedback 
to the user. 

Flowever, most of these services do not support local 
number portability (LNP) at this moment because LNP database is not available 
to the public. LNP is a service that allows users to switch service provider(s) 
while keeping the original number. In this case, the service will not provide a 
correct verification. A workaround for a ported cell phone number is for IMAS to 
send a verification SMS to the user. If he/she receives the SMS, then the service 
provider is a correct entry. If they do not receive it, they must check their entry 
again to ensure they input the correct service provider. 

(4) Cell Phone Model Validation Check. The model of a 
cell phone can be validated by checking the unique identification number 
embedded on the cell phone (by the manufacturer). The International Mobile 
Equipment Identity (IMEI) embedded on every GSM/UMTS cell phone is a 15 or 
17 digit number that provides information on the origin, model, and serial number 
of the device. It is usually found printed on the phone underneath the battery. 
Alternatively, it can be found by dialing the sequence *#06# on the cell phone 
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[28]. The mobile equipment identifier (MEID), found on CDMA cell phones, is 56- 
bit long (14 hex or 18 decimal digits), containing the 8-bit regional code (RR), a 
24-bit manufacturer code, and a 24-bit manufacturer-assigned serial number [29]. 

(5) To Validate GSM Cell Phones. IMAS could leverage 
an online service, the “IMEI number analysis” offered by International Numbering 
Plans. This service analyzes the IMEI and identifies the model and issuing 
authority [30]. Figure 14 shows the output of this service. For CDMA phones, as 
MEID does not contain information on the model, it is impossible to identify the 
model. The only way to identify the model is to query the manufacturer’s 
database which might not be available. Nevertheless, IMAS could use the serial 
number and verify the manufacturer with the Telecommunication Industry 
Association (TIA) website [31]. TIA is responsible for managing and issuing 
MEIDs to manufacturers. If the selected input model does not match the 
manufacturer, IMAS will provide feedback to the user for re-verification. 


Enter IMEI number below 

[359816004276651 || analyse ] 
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c. How to Correct Data-Type Errors 

The data-type errors introduced by attackers are often attacks that 
exploit applications’ failure to validate input entry. These errors could lead to 
system crashes, theft of information or corruption of data. This vulnerability can 
be corrected or mitigated by data-type validation methods. These methods rely 
on three data-type validation models; (1) Accept only known valid data, (2) Reject 
known bad data, and (3) Sanitize bad data. These three data-type models check 
on (1) data type, (2) syntax and (3) length of data entry [32]. They are listed as 
follows: 

• Accept only known valid data model - This is the preferred 
model to validate data whereby applications should only accept 
input that is known to be safe and expected. For example, a valid 
username (defined as ASCII A-Z and 0-9) should be type-checked 
as a string and must be comprised of A-Z and 0-9. It must also be 
bounded by the valid length of the application. 

• Reject known bad data model - This model relies on the 
application knowing about specific malicious payloads, e.g., 
specimens or signatures. Although this strategy can limit exposure, 
it is difficult for any application to maintain an updated database of 
web applications against signatures because signatures change 
very frequently. 

• Sanitize bad data mode/ - This model attempts to make bad data 
harmless, i.e., converting bad data into a common character set. It 
is effective against bad data input but is extremely difficult to 
implement. Hence, it should only be used as a second line of 
defense. 

• This part of the section looks at several well-known web attacks 
that leverage applications’ failure to validate input for exploitation. It 
will show how these attacks are prevented by validation and other 
techniques. 

• Cross Site Scripting (XSS) - This type of attack lies in the 
vulnerability of the application’s script. Often, the victim is tricked 
into making a specific and carefully crafted HTTP request using 
traps. These traps may masquerade in the form of a (1) link in a 
HTML aware e-mail, (2) web based bulletin board or (3) link or 
image embedded in a malicious web site. The traps will then direct 
the malicious request to the web server. Here, the script will read 
just part of the HTTP request and echo it back in full or in part, 
without first sanitizing it. It does not ensure that the entry is free 
from any java script code or HTML tags. 
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Hence, if the request contains a java script, it will be echoed back 
to the user as a response page. The user’s browser will interpret it as a java 
script used by the application to verify its inputs. It will then allow the script to 
access the cookies on the client end. This exposure of all cookies’ allows for 
information to be collected by the attacker. As most 
identification/authentication/authorization information is maintained inside the 
web applications cookies, this will allow the attacker to impersonate the users 
and access their accounts, which is disastrous [33]. 
d. Mitigation Techniques 

There are various mitigation techniques available to prevent XSS. 
Common techniques are as follows. 

• Perform input filtering/data sanitation that looks into the user’s 
inputs such as parameters and HTTP headers and filter against 
HTML tags including java script. The input includes all possible 
sources, e.g., query parameters, body parameters of POST request 
and HTTP headers. 

• Perform correct encoding of dynamic output data. This can prevent 
malicious scripts from being passed to the user. The application 
could make an explicit decision to encode un-trusted data and 
leave trusted data untouched, thus preserving the integrity of the 
mark-up content. 

• Enforce fixed character set on web pages and ensure that the data 
inserted by the system is free from byte sequences containing 
special characters such as “<”. Web pages must be configured to 
inform the browser of what character set to use when submitting 
the form data back to the server. The web pages must also be 
configured to inform the servers’ applications as to what character 
set they need to use internally. This deters any unspecified 
character-encoding entry that might be misinterpreted by the web 
server resulting in a probable attack. 

• Install a third party application firewall, which intercepts XSS 
attacks and blocks them before they reach the web server and 
script. The application firewall validates and inspects the data 
against various HTML tag patterns and rejects the request if there 
are any matches. Thus, it ensures that the malicious input does not 
reach the server and script. 

• Run an automated web application vulnerability tool to inspect the 
web site and launch all variants of attacks it recognizes against all 
scripts. The attacks include trying different parameters, headers 
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and paths. Each input to the application e.g., parameters of all 
scripts, HTTP headers, and paths, is checked with as many 
variations as possible. If the response page contains a java script 
code that the browser can execute, then an XSS vulnerability is 
exposed. 

e. Direct SQL Injection 

This type of attack occurs when the application does not validate 
user entry. This allows attackers to make direct database calls into the database. 
Attackers will typically add a malicious database function in the request and 
cause the database to process and execute their desired function. The 
consequences can be devastating, e.g., the attacker can change the 
administrative password of the system or the value of money deposited into his 
bank account. Thus, it can be seen that a poorly designed web application 
without (or with minimum) a validation function can allow an attacker to retrieve 
and place data in any system at will. 

Direct SQL injection can be used to (1) change SQL values, (2) 
concatenate SQL statements, (3) add function calls and stored-procedures to a 
statement and, (4) typecast and concatenate retrieved data. The following 
exemplifies how each of these attacks can be executed in the request: [34] 

• Changing SQL Values 

UPDATE usertable SET pwd='$INPUT[pwd]' WHERE uid='$lNPUT[uid]'; 

Malicious HTTP request 

http://www.none.to/script?pwd=ngomo&uid=1'+or+uid+like'%25admin%25';--%00 


• Concatenating SQL Statements 

SELECT id,name FROM products WHERE id LIKE '%$INPUT[prod]%'; 

Malicious HTTP request 

http://www.none.to/script?0';insert+into+pg_shadow+usename+values+('hoschi') 


• Adding function calls and stored-procedures to a star statement 

SELECT id,name FROM products WHERE id LIKE '%$INPUT[prod]%'; 

Malicious HTTP request 

http://www.none.to/script?0';EXEC+master..xp_cmdshell{cmd.exe+/c) 
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• Typecast and concatenate retrieved data 

SELECT id,t_nr,x_nr,i_name,last_update,size FROM p_table WHERE size = 
'$INPUT[size]'; 


Malicious HTTP request 

http://www.none.to/script?size=0’+union+select+’1concat{uname|r- 
’||passwd)+as+i_name+'1'+'1'+from+usertable+where+uname+like+'25 

f. Mitigation Techniques 

There are various mitigation techniques available to prevent Direct 
SQL injection. Two techniques are as follows; 

• Perform in-house filtering that looks at the user’s input for SQL 

commands. SQL queries should be built from data values and 
never from other SQL queries or parts thereof. Therefore, the 
filtering will remove special characters used in SQL statements, 
e.g., “-f”, (single quote) and “=”. However, this approach will 

not be able to stop all SQL injection attacks. It can be difficult to 
implement if the input filtering algorithm has to decide whether the 
data, that contains special characters, is destined to become part of 
a SQL query. In addition, as different databases handle special 
characters differently, the filtering algorithm has to know which 
database this query might run against and filter off these special 
characters. 

• Construct all queries with prepared statements and/or 
parameterized stored procedures - A prepared statement or 
parameterized stored procedure is one that encapsulates variables 
and will escape/not encapsulate special characters within them 
automatically. Therefore, any value for the parameters that contain 
SQL commands will be interpreted as special characters and will be 
rejected by the statement. 

These two techniques complement each other and provide the 
defense in depth needed to mitigate SQL injection attacks. 

(1) Direct Qperating System (QS) Commands Attack. 
This type of attack focuses on the system commands that are available to almost 
every programming and scripting language. These languages use system 
commands to utilize the services provided by the QS. File-handling, sending e- 
mail or invoking the QS tools are some common usage commands by web 
applications. However, if the input entry is not validated, the attack will result an 
(1) alteration of system commands, (2) alteration of parameters passed to 
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system commands, (3) execution of additional commands and OS command line 
tools or (4) execution of additional commands within the executed command. All 
of these actions could result in the corruption of data or loss of service. PHP is 
used to develop applications in IMAS. It is advisable to avoid using the following 
commands [35]: 

• Require () 

• Include () 

• Eval() 

• Preg_replace() (with /e modifier) 

• Exec() 

• PassthruO 

• ” (backticks) 

One common mitigation technique used is; 

• Perform an in-house filtering that looks into the user’s input for OS 

commands. The set of commands to filter depends on the scripting 
or programming language. 

(2) Path Traversal Attack. This attack exploits the file 
system of the web server commonly used as a storage repository by many web 
applications. The file system stores their information, which includes images and 
static HTML pages. Web servers are easily accessible by anybody who has 
access to the Internet. An attacker can easily launch an attack on the web server 
by constructing a malicious request using meta-characters such as These 
meta-characters can be used to describe the path of a location or to return data 
about the physical file location if they are not properly checked or validated. This 
vulnerability is referred to as “file disclosure vulnerability.” The attacker may also 
combine this technique with direct OS command attack or direct SQL injection 
attack to launch a specially crafted URL to path traversal attack. This special 
attack allows the attacker to traverse system directories and execute system 
commands. [36] 
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There are two mitigation techniques available to prevent path 
traversal attack. They are as follows: 

• Use path normalization provided by the development language e.g., 
PHP, Perl. 

• Validate the input entry to remove any offending path strings such 
as as well as their Unicode variants from the system input. 

(3) Null Bytes Attack. This type of attack exploits the 
vulnerability of the underlying programming language that treats null byte “\0” as 
the termination of a string. If the input is not validated, a malicious entry 
containing the null byte will be accepted as a valid entry by the application. This, 
in turn, will be passed to the underlying applications, which interpret it differently. 
For example, “AAA\0BBB” is accepted by the applications as a valid entry but is 
interpreted as “AAA” by the lower-layer applications. This attack can be used to 

(1) disclose physical paths, files and OS-information, (2) truncate strings, (3) 
bypass validity checks that look for sub-strings in parameters and (4) cut off 
strings passed to SQL queries. 

Perl, Java and PHP are some of the most popular scripting 
and programming languages that have this vulnerability. Since PHP is used to 
develop applications in IMAS, it is pertinent to rectify or mitigate this vulnerability. 
[37] 

One common mitigation technique used is; 

• Validate all input entries by checking on all null bytes before 
passing to underlying applications. 

(4) Parameter Manipulation Attack. This type of attack 
changes the value of parameters sent from the user’s browser to the web 
application to perform a task that is not originally intended. Under this form of 
attack, the attacker will always target parameters originated from the (1) cookies, 

(2) form fields, (3) URL query strings or (4) HTTP headers. [38] 

(5) Cookies Manipulation Attack. Cookies have always 
been the preferred method to maintain state in a stateless HTTP protocol 
because they are a convenient mechanism to store information. Furthermore, 
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they are used by many web applications to store user preference and session 
tokens. However, the value could easily be changed by a user and sent to the 
server with the URL request regardless if it is a persistent cookie, non-persistent 
cookie, secure cookie or insecure cookie. 

Persistent cookies enable a web application to remember 
the user by establishing an information file on the user’s system. A non-persistent 
cookie is stored in the RAM on the user’s system and is destroyed when the 
browser is closed. A secure cookie is used in secure communication sessions 
only, e.g., HTTPS. It provides three types of services: (1) authentication, (2) 
integrity and (3) confidentiality. An insecure cookie is used to manage session 
cookies and can be used in both secure (HTTPS) and normal connections 
(HTTP). 


In addition, most cookies do not offer any encryption 
protection. This process creates an opportunity for any attacker to modify the 
cookie content at will. Typically, most attackers will launch this type of attack on 
session tokens that make authorization decisions. [39] 

There are various mitigation techniques available to prevent 
a cookies manipulation attack. Three techniques used are as follows: 

• The most reliable way to ensure that the data is returned un¬ 
modified is to implement a session token. A session token is used 
to associate the session to the userid. At the server-end, a session 
table is set up to map the user’s session to the user’s data 
variables in the cache/database. When an application needs to 
check a user’s property, it will check the userid with its session 
table and refer to the user’s data variables in the cache/database. 

• Build detection hooks to evaluate the cookie for any infeasible 
combinations that would indicate tampering, e.g., a “detection” flag 
embedded in the cookie. 

• Encrypt the cookie to prevent it from being tampered. The cookie 
should be hashed and the hash is compared when it is returned to 
the application or it could be encrypted using symmetric encryption. 
However, the latter approach will not work if the system is 
penetrated or compromised. In this situation, a new key will need to 
be generated. 
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(6) HTML Form Field Manipulation Attack. Most of the 
web applications used provide a mechanism that allows users to input 
information. This information is often stored as form field values and sent to the 
web application as an HTTP request (GET or POST). HTML can also store field 
values as hidden fields, which are not presented to the screen by the browser. 
These hidden fields are collected and submitted as parameters during form 
submission. However, these form fields, even though they are pre-selected (such 
as drop-down/checkboxes, free form or hidden), can easily be manipulated by an 
attacker. The attacker can save the source of the web page, edit it and reload 
the page in the web browser before submitting the value back to the server. This 
poses a serious threat as the attacker may change many form fields, e.g., the 
value, the maximum length tag of the input entry and the visibility of the display. 
This results in changing the original and truthful values of the form fields.[40] 

There are various mitigation techniques available to prevent 
HTML form field manipulation attack. Two techniques used are as follows: 

• Instead of using hidden form fields that reference the properties of 
a field, which is subjected to changes, it is advisable to use session 
token to reference properties stored in a server-side cache. Thus, 
when an application needs to check a user property, it checks the 
session cookie with its session table and points to the user’s data 
variable in the cache or database. 

• Detect the changes in HTML form field manipulation - In this 
approach, the name and value pair of the hidden field in the form is 
concatenated together into a single string. A secret key is 
appended to this concatenated string to form what is known as an 
outgoing form message (OFM). The secret key will not be sent with 
the form but is kept at the server-end. The OFM is then hashed to 
generate an outgoing form digest (OFD) that is added to the form 
as an additional hidden field. When the form is submitted back to 
the server, the incoming name and value pair are concatenated 
along with the secret key into an incoming form message (IFM). 
Next, a hash is computed to generate the incoming form digest 
(IFD). If the IFD does not match the OFD that was sent along with 
the form, then the hidden field is detected as altered and the 
applications can choose to ignore this submission. This same 
technique can be used to prevent URL parameter tampering as 
seen in the next section. 
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(7) URL Manipulation Attack. In many web applications, 
HTML forms are normally submitted using one of two methods: GET or POST. In 
the GET method, all the element names and their values will appear in the query 
string of the next URL the user sees. Tampering with query strings is very easy; 
all the user has to do is look at the address bar of the web browser and modify 
the values of the URL. For instance, this attack can be carried out by a user 
requesting the server credit $100.00 into his account numbered 12345 instead of 
a debit transaction of $100.00. This simple manipulation technique can have 
devastating effects on financial institutions. [41] An example of this command is 
as follows: 

http://www.victim.com/example?accountnumber=12345&debitamount=100 

http://www.victim.com/example?accountnumber=12345&creditamount=100 

Unfortunately, HTML form is not the only mechanism that 
has these vulnerabilities. Almost all navigation done on the Internet is via 
hyperlinks. When a user clicks on a hyperlink to navigate from one site to the 
other, or within an application, he is sending a GET request. This GET request 
has a query string with parameters similar to the form. This allows any attacker to 
look at the URL window of the browser and change the parameters. 

There are several techniques used to solve URL 
manipulation problems and each technique can be used in different situations. 
The best solution is to avoid putting parameters into a query string (or hidden 
form string). 

• POST instead of the GET method - The POST method puts 
parameters to be passed in the body of the request which is not 
visible within the URL. This eliminates the opportunity for the user 
to make changes to the URL so that it may bypass the application. 
However, it does not prevent advanced hackers that typically have 
the tools from seeing and manipulating the POST parameters. 

• Encrypting or signing the entire query string or all hidden form field 
values - This technique prevents a user from setting the value or 
seeing the value. This technique is applicable to situations where 
the parameter value is confidential such as a password. 
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• Replace variables in URL with page token - This technique 
replaces all variables in the URL with a page token. A page token is 
a random number or “nonce” that is only valid with a particular page. 
It is not valid in another page. At the server end, a page table is 
created to map the variables to the page token. Thus, whenever a 
request is made by the user and sent to the application, the 
application will check the value of the page token. If the page token 
does not match the value in the table, it indicates that the user has 
manipulated the variable and the request is rejected. In addition, 
because the variable is now a random number, the user will not 
know the actual parameter, therefore, deterring the user from 
making any changes. 

• Hashing the value of the URL query string (or hidden form fields) 
and append it to the URL - This approach can detect manipulations. 
If the URL value is changed, the hash value will not match and the 
application is able to detect it. However, this method does not 
prevent the user from seeing a value; it only prevents the attacker 
from changing the value. 

(8) HTTP Header. HTTP headers are control information 
passed from web clients to web servers based on HTTP requests and from web 
servers to HTTP clients based on HTTP responses. These headers are 
sometimes used by web applications to determine the URL of the web page from 
which the request was originated, e.g., a Referer header. This check is to prevent 
attackers from saving the web pages, modifying them and re-posting them from 
their own computer. Although most web browsers do not allow header 
modification, an attacker is still able to modify the header with his own script or 
by using freely available proxies that allow easy modification. This will lead to 
SQL injection or a falsified URL. [42] 

There are various mitigation techniques available to prevent 
HTTP header attack. One technique used is as follows: 

• Sign and preferably encrypt the header, such as in the case of 
cookies. However, it is key to note that a Referer header should 
never be used as any security decision. 

Two well known attacks include (1) HTTP request smuggling 
(HRS) and (2) HTTP response splitting (HRSP). These attacks exploit the web 
server and intermediate devices such as a (1) cache server, (2) proxy server or 
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(3) web application firewall. Failures to properly handle malformed inbound 
HTTP requests, i.e., they read the request differently, allows the attacker to 
achieve malicious intent. 

(9) HTTP Request Smuggling Attack. In this attack, the 
attacker sends multiple specially crafted HTTP requests that cause the two 
attacked entities (web server and intermediate devices) to see different sets of 
requests. This type of attack allows the attacker to smuggle a request to one 
device without the other device being aware of it. Various types of smuggling 
attacks are: (1) bypassing the application firewall protection, (2) web cache 
poisoning, (3) session hijacking and (4) cross site attacking. Noteworthy, the 
most vital attack is the attacker’s ability to bypass the application firewall 
protection which is deployed in many web sites’ protections. In the web cache 
poisoning attack, the smuggled request tricks the cache server into 
unintentionally associating a URL to another URL’s page (content) and directs 
the content for the URL. In the web application firewall attack, the smuggled 
request can be a worm (like Nimda or Code Red) or buffer overflow attack, 
targeting the server. In this type of attack, the attacker can manipulate the web 
server’s request/response sequencing, allowing for credential hijacking and other 
malicious outcomes, making it one of the most severe attacks. [43] 

There are various mitigation techniques available to prevent 
HRS attack. These techniques are as follows: 

• Application firewall - Although this form of attack can bypass 
application firewalls, an application firewall is still recommended to 
be installed to detect and deter this attack in deployment where 
both cache servers and web servers are deployed. To ensure the 
firewall is not vulnerable to this form of attack, it needs to be 
assured that it is secure against this type of attack either through 
server patches or algorithm. 

• Deploy a web server that employs a stricter HTTP procedure such 
as an Apache server. 

• Allow only secure communications, i.e., SSL communication 
(HTTPS instead HTTP) and terminate the client session after each 
request or switch all pages to non-cacheable. This process will 
prevent poisoning in the cache-web server situation. 
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(10) HTTP Response Splitting Attack. This type of attack 
exploits the application’s failure to reject illegal user input; input that contains 
malicious or unexpected characters, specifically the CR (carriage return) and LF 
(line-feed) characters. Here, the attacker sends two requests through the 
intermediate device. The first request is a single specially crafted request that 
forces the web server to generate an output stream composed of two responses. 
These two responses are then interpreted by the intermediate device as two 
HTTP responses instead of one response, as done in the normal case. The 
second request would typically ask for some resource on the web server. 
However, the second request would be matched by the intermediate device to 
the second HTTP request response, which is fully controlled by the attacker. The 
attacker, therefore, tricks the intermediate device into believing the server 
resource is the second HTTP response, while it is, in fact, data forged by the 
attacker through the web server in the first request. 

This form of attack can lead to proxy cache poisoning known 
as “classic defacement” where the user is directed to a web site controlled by the 
attacker. Furthermore, it can result in browser cache poisoning where the poison 
page stays in the cache, waiting for the user to load it. Lastly, this form of attack 
can be used to attack a script created to handle HTTP errors or to defeat a 
character-based input filter. [44] 

There are various mitigation techniques available to prevent 
HRSP attack. These techniques are as follows: 

• Perform input filtering that validates all input entries and removes 
the CRs and LFs (and all other hazardous characters) before 
embedding data into any HTTP response headers, particularly 
when setting the cookies and re-directing. It is possible to use third 
party tools (e.g.. Sanctum’s Appshield and AppScan) to defend 
against CR/LF injection and to test for the existence of holes before 
application deployment. 

• Always patch the application engine to ensure it is up-to-date. 

• Ensure the application is accessed through a unique IP address 
(i.e., the same IP address is not used for other applications, as it is 
with virtual hosting). 
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4. Database Process 

Once the data has been validated and sanitized by the applications, the 
data will be inserted into the database for storage. The stored data can also be 
retrieved from the database for output response. 

a. Vulnerability 

Although the database is physically separated from the web and 
application server and protected by ACLs and other security mechanisms, e.g 
firewalls, the data is still subjected to subversion if the database system is 
compromised and the data is being snooped on the Internet. Hence, besides 
physical access controls, other security mechanisms must be in place to encrypt 
the data. These security measures must be in place whether data are in the 
database or in transit from the application server to the database. The data will 
be viewed as “garbage” by others if it is taken out of the context of the database 
or if it is snooped by others while it is in transit from the application server to the 
database server. 

b. How to Protect the Data 

MySQL, the database used by I MAS, offers several methods to 
protect the data in transit or in storage. IMAS must use these methods to protect 
the data. The methods are as follows. 

(1) Data Encryption into Database. MySQL provides 
several methods to encrypt the data in the database. Among these methods, one 
method is recommended because of its strong encryption algorithms, the 
Advanced Encryption Standard (AES) encryption and decryption. It is 
recommended that all of the data or at a minimum, the most sensitive data, e.g., 
passwords and cell phones/models in IMAS be encrypted using these methods. 
[45] 
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• AES_ENCRYPT ( ) and AES_DECRYPT ( ) - these functions 
encrypt and decrypt data using the AES algorithm. It is encoded 
with a 128-bit key length, but can be encoded with a 256-bit key 
length by modifying the source. By far, AES_ENCRYPT() and 
AES_DECRYPT() are considered to be the most cryptographically 
secure encryption functions currently available in MySQL. To store 
the data in encrypted form inside the database, the user uses the 
following command: 

INSERT INTO t VALUES (1 ,AES_ENCRYPT('text','password')); 

(2) Hashing. MySQL also supports several methods to 
generate hashes for its data to be stored inside the database. These hash¬ 
generating functions are based on well known algorithms e.g., SHA (secure hash 
algorithm) or variant SHA1 and MD5 (message digest 5). To protect the integrity 
of the data, especially sensitive data (passwords, cell phone numbers or cell 
phone models, and encryption keys), it is recommended to hash these sensitive 
data and store the hashes in a different storage area. The storage area needs to 
be physically separated from the database so that it will not be compromised/ 
tampered if the database system is compromised. A script should be written to 
periodically hash these sensitive data in the database. These hashes should then 
be checked against the stored-away-hashes to ensure none of the data was 
tampered with or modified. 

• SHA() or SHA1( ) - this function calculates and computes a SHA- 
1 160-bit checksum for a given input based on SHA. SHA1() or 
SHA() is considered cryptographically more secure than MD5(). 
The following command shows how to hash a string using SHA1. 

SELECT SHA1 (‘password’) 

• MD5 ( ) - this function calculates and computes a MD5 128-bit 
checksum for a given input. The following command shows how to 
hash a string using MD5. 

SELECT MD5 (‘password’) 
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(3) Secure Connection between Database and Client. 
MySQL supports a secure connection using a SSL between the database server 
and its clients. In the context of this thesis, it refers to the application server 
which sends the validated and sanitized data to the database. This prevents any 
attacker snooping on the network from seeing the data in dear-text. The secure 
connections can be set up using the bundled yaSSL that comes with MySQL or 
QpenSSL. OpenSSL is open-source software that generates digital certificates 
and the keys (public and private) to support SSL. The secure connections in 
MySQL are based on QpenSSL application interface (API) and are available 
through MySQL C API. [46] 

(4) Data Backup. Data backup is a critical process that 
protects data from any data loss events. IMAS must backup the database (a full 
backup or an incremental backup) periodically for speedy recovery against server 
crash, power failure, file system crash, hardware failure or system exploitation. 
MySQL offers both full and incremental backup options. A user can perform a 
one-time full-backup to capture the entire database and then use incremental 
backups to capture subsequent changes. This backup plan optimizes the long 
(full backup) and short (incremental) backup times for the backup operation. In 
addition, MySQL allows a user to recover data by specifying the time (starting 
time or stopping time) or position (in the database) of recovery to recover the 
data. MySQL also offers error-check capability on the tables and table recovery 
capability that handles data corruption issues. [47] 

To better safeguard the data, all backups should be copied 
to a media that is not housed in the same server as the database. Additionally, it 
should be kept in a safe place, e.g., tape or DVD in a safe or off-site. 

5. Session Login and Profiie Updates 

After the user has completed the registration, the user will then log in 
again to either re-confirm the account or make changes to the profile. Before 
being allowed access into the system and make any changes, it is necessary to 
login and authenticate to the system with the username and password. As 

mentioned earlier, the IMAS system will implement either a one-factor l&A 
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(identification and authentication) or a two factor l&A. A one-factor l&A uses only 
the IMAS username and password. However, the two-factor l&A requires the 
user to authenticate using the CAC card (containing the user’s private key) prior 
to authentication to the IMAS system. Upon successful authentication, the 
system will create a session and issue a session token to the user. This session 
token will allow the system to associate the identity of the user to the application 
for accountability. Furthermore, it provides the context in which all their 
interactions with the server will be evaluated. [48] 

Session tokens are often stored in cookies (created by the web 
application) inside the user’s stations. However, they may also be stored in a 
static URL, dynamically written URL, hidden in the HTML of a web page or a 
combination of these methods. Regardless of the form used, a secure session 
management scheme must be implemented because a poorly designed/ 
implemented scheme can lead to compromised user accounts. The following 
section discusses how to implement a secure session management scheme. 

a. Secure Authentication 

Authentication is the first stage in creating a session. This stage is 
especially prone to security attacks because once a session is created; all further 
actions associated with this “legal” session need no further authentication. Hence, 
a strong authentication mechanism is required. To prevent any subversion, all 
authentication information should always be passed over a secure medium. In 
the context of this thesis, the secure medium is established over SSL. In addition, 
to increase the resistance against dictionary and brute force attack, a well-built 
password (requiring a minimum number of characters, consisting of a 
combination of letters, numbers and other special characters), is needed. 

Authentication is also subject to severe enumeration attacks from 
attackers in the hope of accessing the system. Therefore, it is important to 
ensure the system contains a delay to slow down the enumeration. A threshold 
should also be set to count the multiple failed authentications for every account in 
the system so that if the threshold is reached, a warning is generated. This will 

prompt the user to take necessary actions. 
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Both of these techniques serve as a measure to monitor 
consecutive attempts and number of failed attempts over a specified period of 
time. 

b. Session Maintenance 

Once the user has successfully authenticated, all actions taken will 
not be authenticated and will only be identified by a session token/identifier. Thus, 
it is crucial to create a secure session identifier that is user unique, non- 
predictable, and resistant to reverse-engineering. The identifier must be 
cryptographically strong, signed and time-stamped. Additionally, the 
token/identifier should always be created from a trusted random generator, e.g.. 
Yarrow, EGADS, and encrypted using a well known encryption algorithm, e.g., 
AES or 3DES. To further enhance the security, all session tokens should be 
associated with an HTTP instance to prevent hijacking and replay attacks. One 
such mechanism involves using page tokens, which are unique for any 
generated page and can be tied to session tokens on the servers. 

Hijacking an existing session is a common technique employed by 
attackers. To prevent this form of attack when the user switches from secure to 
non-secure pages, the system should always use a different session id. If the 
common session id must be used for secure and non-secure pages, then the 
secure pages must always authenticate the user before negotiating new keys. 
This step will lessen the vulnerability of an attacker using the hijacked session 
token to access a secure page. If the user is not re-authenticated, the attacker 
with the hijacked session token/id, could access the secure page and obtain 
sensitive information. This leads to a confidentiality breach. 

Other measures include using long key space for token/identifier 
creation and managing the time-window of the session. 

c. Session Management 

Session termination is an important aspect of session management. 
Any unattended sessions left open over a period of time open a security gap for 
potential breaches. Similarly, any non-terminated sessions permit attacker to 


52 



gain access to specific sessions which can lead to identity theft. Hence, it is vital 
to reduce the vulnerability window of the user(s) session. The session should be 
terminated in the following conditions: 

• Inactive session - A session that has been inactive for a 
predetermined period of time should be terminated to reduce the 
window of attack. Typically, this time ranges from 15-30 minutes, 
depending on the preference of the system. 

• Long session - To prevent session hijacking and a brute force 
attack on existing active session(s), the active session will be 
terminated after it has reached a prefixed maximum time. 
Thereafter, the user is required to re-authenticate so that a new 
session token/id is created. This reduces the window of attack on a 
replay attack. 

• Security Error Logoff Session - Any security error encountered in 
the application should result in an immediate termination of the 
session. This prevents any orphaned session from being taken over 
by an attacker. 

• Logoff/Logout Session - A session should always enable the user 
to logoff/logout the session as the most secure section. 

• In addition to a session termination scheme, other session 
management schemes include [49]: 

• Session Forging/Brute Force Detection (“booby trap” session 
tokens) - This scheme measures against a brute force attack 
where the attacker tries hundreds to thousands of session tokens 
embedded in a legitimate URL or cookie. These tokens are never 
actually assigned to the users but reside on the server end. They 
will detect this anomaly and ban the originating IP address or lock 
out the account. 

• Session Re-Authentication - This scheme prompts the user for a 
re-authentication and is applicable when a critical user action such 
as a money transfer or the purchase of a big-ticket item has to be 
made. In the IMAS context, re-authentication may be activated if 
the user tries to change the e-mail address or cell phone number 
that impacts the delivery of the alerts. 

• Session Tokens on Logout - These days, it is common practice for 
users on the move to use widespread terminals in Internet kiosks, 
e.g., airports and cybercafes, to access the Internet. This provides 
a new set of risks because a browser only removes session 
cookies when a browser thread is closed and most Internet kiosks 
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maintain the same browser and do not close it. Thus, it is 
necessary to overwrite session cookies when the user logs off the 
application. 


d. User Profile Update 

Once the user logs into IMAS and is issued a session token/id, a 
default calendar view of the current week will be presented to the user. An 
example of this is shown in Figure 15. 
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Figure 15. Calendar view 


From this point, the user can select a date and enter the following 
information in the event entry menu: 

• Description of event 

• Duration of event 
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• Context of event 

• Types of alerts they prefer 
Figure 16 illustrates this process. 
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When the user submits preferences, IMAS will perform the data- 
correction and data-type check. In the data-correction check, IMAS will verify two 
fields: (1) date and (2) context along with type of alerts, to prevent user mistakes. 

The date entered must not be earlier than the current date because 
any event before the present date and time is obsolete. Additionally, the date 
must not be a date too distant (one year later) as the system does not recognize 
this as a realistic event. The context selection will determine the type of alerts. 
Thus, a binding algorithm should be built into the software to ensure the alert 
types correspond to the context selected. The data type validation shall follow the 
recommendations made in earlier section. 
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D. ADDITIONAL SECURITY MEASURES 

In addition to the recommendations already discussed, there are several 
other measures that need to be implemented to strengthen the security of the 
web applications. This section covers some of these measures. 

1. Privacy Consideration 

In some countries, it is mandated by law to safeguard a user’s privacy. 
Hence, systems that deal with private and sensitive information must take 
additional steps to ensure a user’s privacy is maintained. The following list 
provides recommendations to protect a user’s privacy [50]: 

a. Warnings 

The system should warn users of the danger of sharing common 
PCs such as those in Internet kiosks or libraries. Warnings, at a minimum, should 
include: 

• Do not access private data from common PCs because of the 
possibility of pages being retained in the browser cache 

• Recommendations/steps to clear the cache in the browser after 
accessing private data 

• Fact that “temp” files can still remain in the PC after use 

• Fact that the proxy server and other LAN users may be able to 
intercept traffic 

b. Page Parameters 

The system needs to ensure that personal data is displayed only 
when necessary. All private data must be masked or partially-masked to prevent 
people from seeing it. In addition, if possible, the data should not be stored in the 
cache of the PC. All data should be cleared and removed when the user ends the 
session. This process can be achieved by setting the (1) expire time, (2) no¬ 
cache tags (headers) and (3) no-pragma-cache tags (headers), of the web pages 
when designing the pages. [51] 

2. Event Logging 

Event logging is essential to providing key security information about a 
web application and its associated processes and technologies. It captures the 
following crucial information: 
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• Suspicious behavior taking place in the system that can be fed to 
an intrusion detection system in real-time for root-cause analysis. 

• User’s actions to provide individual accountability in the web 
application system. 

• Events that are helpful for the reconstruction of events after a 
problem has occurred, be it security related or not. Event 
reconstruction permits system administrators or forensic 
investigators to determine the extent of an intruder’s activities and 
expedite the recovery process. 

Failure to enable proper event logging mechanisms in the web 
applications may result in the system being unable to detect unauthorized access 
attempts. Hence, it is strongly recommended that logging be enabled in IMAS. 

3. Compartmentalization of Data 

Data is the most critical part of any system and information leakage is 
deemed disastrous. Hence, sufficient effort and measures must be taken to 
protect data. 

One such approach is accomplished through compartmentalization. 
Typically, data can be decomposed as sensitive (private) and non-sensitive 
(public). The first thing a programmer needs to do in the design of the IMAS 
system is to identify the sensitivity or classification of the data so that it is 
possible to separate them either physically (separate hard-drive) or logically (in 
different folders). Putting both sensitive and non-sensitive data together, creates 
a higher risk of compromising the confidentiality of the data, even though access 
control might be in place on each file. This is because an authorized person who 
has access to the directory and/or files could work around such controls and gain 
access to the files he/she is not authorized. 

In addition, by compartmentalizing the data, it offers an additional layer of 
defense and the flexibility to better control access to the data. The data entry 
points,, points where users access the data from the outside, can also be 
identified and various access control mechanisms, such as mandatory access 
control (MAC), discretionary access control (DAC) or even role-based access 
control (RBAC), can be implemented. This strengthens the access control to the 
data. 
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MAC is implemented by the system based on an access policy 
established by the data owner. It will decide on the resources or files the users 
are allowed to access and what privileges they have based on the login 
credentials they provide. 

DAC is an access policy determined by the owner of the file or other 
resources. The owner decides who is allowed access to the file and what type of 
privileges. 

RBAC is an access policy based on the roles the person is tasked to 
perform. The permissions and privileges are tied directly to the role. 

By compartmentalizing, the system can encrypt and hash the data to 
provide an additional level of confidentiality and integrity protection. Thus, it is 
recommended that IMAS compartmentalize the data. 

4. Encryption 

Encryption is a key aspect in providing protection to the web applications. 
It protects the data from being modified and viewed by any un-authorized user(s). 
However, it should be noted that there are many types of encryptions, each 
serving a specific layer. SSL is a form of encryption that only encrypts data in the 
transport layer, protecting the data in transit. It is not specific to the application 
and will not provide protection to the application layer. Thus, other types of 
encryption are needed to encrypt the specific fields in the HTML forms and mask 
off the links within the pages. It is also necessary to obscure the content and 
structure of the application to avoid probing. All fields and links used by the 
server should also be signed, encrypted or compared with values stored in the 
backend to avoid/detect manipulation. Likewise, data stored in the database 
should be encrypted and hashes generated to protect the data and detect un¬ 
authorized modification. 

5. Caching 

Caching in the form of a cache server is commonly used in many web 
applications. It is used to enhance performance because it buffers/caches the 
most frequently-used content and serves it on behalf of the web server. This 
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eliminates the need to request it from the web server on every request. However, 
this poses a security hazard because if any content pages, i.e., non-multimedia, 
are put on external unprotected cache servers, these pages (which are part of 
the application) will expose the application to changes in the pages. If this occurs, 
it will cause a loss of control over the application flow and increase the 
complexity in the security design. 

In addition, to prevent private records from remaining on the user’s 
computers, especially in a common-use terminal, after the web page is served, it 
is recommended to use a “no-cache” HTTP header on the web page. Removal of 
the page by setting this indicator not only adds to the obscurity, but also protects 
the user’s private data from being copied or manipulated. 

6. Production Site 

The production server used to host the web application should always be 
separated from the internal servers, servers that belong to the Intranet. This 
process is needed so that the impact on the servers can be contained. 
Additionally, the server should not run other software that might disrupt the web 
application. Furthermore, the server should never be used as a development 
server to develop an application. This process could leave temporary, old and 
saved files that were created during the development phase on the server. These 
files might provide “holes” and traces for the attacker to exploit. 

The production server should maintain a sterile environment and all new 
development shall be done and verified on a development server (which is on a 
separate domain from the production server) before porting it over to the 
production server. The production server should never be administered from 
outside the domain. It needs to be administered within the domain to prevent any 
abuse. All administration should be executed locally on the production server to 
prevent any attacks (from inside and outside). 

7. DMZ 

DMZ is a crucial component of the periphery and network defense for any 
organization. It provides not only network level protection but also creates a safe 

environment for web applications. The DMZ segregates the external-facing 
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machines from the internal machines, thereby separating the web applications 
from each other. By using the DMZ, it permits building differential access for 
external users. Additionally, it prevents internal DMZ users from accessing the 
applications through the Intranet or other access methods. 

E. CHAPTER SUMMARY 

This chapter, discussed how vulnerabilities can affect the system through 
the design of the system and its processes. In the system design, it was noted 
that a single box implementation suffers from a single-point of failure and does 
not offer the flexibility to be scalable and provide high availability. Therefore, it 
was recommended to separate the applications into different tiers for better 
management control. Other security mechanisms were also proposed to be 
applied at each tier to secure the system. 

In the design of the applications/processes, it was observed that most well 
known web attacks exploit the application’s failure to validate the input entry. This 
in turn allows attackers to introduce malicious codes into the system. It was 
recommended to use various data validation techniques to prevent these 
vulnerabilities. 

This chapter also proposed implementing a secure session management 
scheme and other security mechanisms to secure IMAS. 
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IV. CONCLUSIONS 


All systems suffer from vulnerabilities due to bugs found in components 
supporting the system. These bugs include (1) errors in software code, (2) 
software design, and (3) mis-configurations in installations. 

IMAS, like other systems, also suffers from vulnerabilities. In this thesis, 
vulnerabilities were identified in the following areas: (1) design and 
implementation of IMAS, (2) COTS products used and (3) in-house developed 
processes/applications. 

The single-box implementation of IMAS suffers from a number of 
vulnerabilities. These are: (1) it is a single point of failure, (2) data might be 
leaked if the box is exploited, (3) it can be used as a launching pad against other 
corporate systems if the system is on a corporate network and (4) it does not 
offer the flexibility to apply appropriate security options on different applications. 
In addition, the management control of system access and services running on 
the box is complicated. This implementation does not scale well. 

COTS products used in IMAS contain vulnerabilities that are due to errors 
in software code, software design and configuration. Examples include (1) failure 
to check and sanitize malicious input entry by applications, (2) enable un-used 
services and accounts and (3) weak passwords. 

The in-house developed processes/applications contain vulnerabilities due 
to their failure to inspect and sanitize inputs. This opens a security gap which 
many well-known web attacks can exploit. This results in system crashes, theft of 
information and corruption of data. 

This thesis recommended several solutions to correct and prevent noted 
vulnerabilities. .A 3-tier architecture is recommended for the design and 
implementation of IMAS. This architecture separates applications and data into 
different tiers and resolves the issues encountered in a single-box 
implementation. COTS software used in IMAS are recommended to keep the 
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software version up-to-date so that they are free from reported vulnerabilities. 
This is achieved by subscribing to vulnerability alert reports and continuously 
applying patches and fixes to the software whenever vulnerabilities are reported. 
In addition, recommendations were made to disable un-used accounts and 
services in order to keep the system secure. 

The in-house developed applications/processes are recommended to 
incorporate numerous validation and filtering techniques to deter common web 
attacks (that leverage on applications’ failure to validate input entry). This 
includes proposing various types of data-type and data-correction validation 
techniques for different fields used in IMAS. Furthermore, ways to implement 
secure session management and data protection inside the database are also 
recommended to enhance the process security of IMAS. 

Other security measures such as (1) privacy consideration, (2) event 
logging, (3) compartmentalization of data, (4) cache implementation, (5) 
segregating the roles of the production server and (5) deployment of IMAS in 
DMZ, are recommended to enhance the security of IMAS. 

Lastly, it should be noted that vulnerabilities come from all components 
supporting IMAS. Hence, efforts must be taken to ensure each component is 
continuously analyzed to decrease vulnerabilities. This includes in-house 
developed applications and the design of the database. As these two areas were 
not covered in this thesis, it is recommended that future studies be made in these 
areas to identify probable vulnerabilities. The code of the application should be 
reviewed by a panel of security programmers to ensure it is free from design and 
code errors. Likewise, the design and implementation of the database should 
also be reviewed to ensure it does not contain errors. The removal of errors will 
make IMAS more secure. 
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